A Configuration Management Database (CMDB) is a database that is used to retain information about the components in an information system (and the relationships between those components) that are used by an organization's Information Technology (IT) services. In this context, system components are often referred to as “configuration items.” A configuration item can be any conceivable resource or component, including software, hardware, documentation, facilities and personnel, as well as any combination of these. The process of configuration management seeks to specify, control, and track configuration items and any changes made to them in a comprehensive and systematic fashion.
The Information Technology Infrastructure Library (ITIL®) best practices standards include specifications for configuration management. According to ITIL specifications, the four major tasks of configuration management are: (1) identification of configuration items to be included in the CMDB; (2) control of data to ensure that it can only be changed by authorized individuals; (3) status maintenance, which involves ensuring that the current status of any configuration item is consistently recorded and kept updated; and (4) verification, through audits and reviews of the data to ensure that it is accurate. (ITIL is a registered trademark of The Lords Commissioners of Her Majesty's Treasury Acting Through The Office of Government Commerce and Central Computer and Telecomunications Agency, United Kingdom.)
Within a configuration database, the concept of data federation is an important scalability and complexity management issue. Generally speaking, data federation is the concept of storing additional or related data about a configuration item (stored in a first data store) in another, second, product or database. This approach to distributing data keeps the size, scope and responsibility of the configuration database controlled and allows the use of existing databases as they currently exist.
In the prior art, federated data is generally accessed by manually executing an application distinct from the federated database. For example, federated data may be retained in a second database (accessible through a separate database management system) or a distinct product (such as a separate configuration management application). Data federated in this manner may be accessed by developing customized source integration logic or by invoking a pre-determined or fixed instance of a second application. In the first of these approaches, custom logic (i.e., software) is developed for each federated database that allows a more automated interaction with the specified data store. In the second approach, the second application is used to manually search for the desired data. In yet a third approach, links to an application that could manipulate an instance of a federated data object are provided, but no ability to modify the invocation of this link (including parameter passing) is possible.
Thus, it would be beneficial to provide a mechanism to automatically and dynamically invoke a specified application from within a database in general, and a configuration management database in particular.